git 可謂現在工程師不可不知的生產力工具，不過今天只會提到 git 的線上教學資源，然而這篇要介紹的是 GitHub Flow。

Git & GitHub

關於 git

git 是一套分散式版本控制系統，是為了更好管理Linux內核而開發的，現在也是多數工程師開發專案會用的一項版本控管工具。
如果想學的，就到以下連結學學看吧！

• 連猴子都能懂的 Git 入門指南
• 為你自己學 Git

關於 GitHub

GitHub 是一個免費提供 Git Server 的圖形介面管理平台，也稱為全球最大的工程師社群交友平台（笑），會有此暱稱也不是玩笑話，基本上多數的開源專案都是透過 GitHub 進行開發管理、維護、溝通，雖然現在 GitHub 被微軟收購後很多專案都移動到 GitLab 了（笑）

GitHub 除了是 Git Server，上文提到「開發管理、維護、溝通」就是下段要說的 GitHub Flow，也是參與開源專案的重中之重。

GitHub Flow

再講 GitHub Flow 前要先介紹簡單提一下 Git Flow，請見以下

Git Flow

1. clone
2. checkout & branch
3. add
4. commit
5. push

基礎的四個步驟涵括開分支、新增/修改檔案、提交到本地 repo、上傳到遠端
然而 GitHub Flow 則是大概長這樣

GitHub Flow

0. Issue
1. fork
2. clone
3. checkout & branch
4. add
5. commit
6. push
7. Pull Requests(PRs)
8. Review
9. Merge

第零步驟稍後在說，而第一個步驟是複製一個想要貢獻的專案到自己的名下，然後步驟 2-6 就是單純的 Git Flow，根據要修改的 Bug 或是要開發的功能開分支進行修改（一般來說不會在 master 分支進行修改），最後推到自己在 GitHub 上面的專案，然後將這個修改送回原始專案，經過專案維護者的審核，有可能會進行修改，修改完都沒問題就完成 Merge。

開源貢獻之 Issue

當你要進行開源貢獻之前，最重要的事情不是直接開發，而是搞清楚狀況！怎麼說呢？一個專案的貢獻者很多，如果大家都沒經過溝通就著手開發，很容易就導致「重造輪子」的問題，而且 GitHub 上的紀錄就是累積工程師貢獻的證明，如果沒有好好管理，只怕有新的人想貢獻都難，因此首先來認識一下 Issue 的作用

Issue 用途與注意事項

• 用來詢問 bug
• 詢問是否可以開發某項功能
• 討論問題（這個不一定，因為有些專案有類似 IRC 可以即時溝通的地方）
• 追蹤 bug 與 Feature

Issue explore

當你對某個功能有疑問，或是想開發新的功能，善用搜尋的功能是一個好習慣，請看圖例

在 filter 的地方輸入關鍵字，或是可以學習一下 tag 搜尋法

開源貢獻之 PRs 與 Review

PRs 雖然是最後的步驟，不過其實送出 PRs 後的 Review 是相當重要的，另外也可以透過

跟上文一樣透過搜尋來鎖定可能正在開發的功能

PRs 說明與注意事項

• 根據自己修改的程式碼申請送回原始專案
• 不一定會被 merge 喔！
• 請注意 coding style！
• 請先閱讀 CONTRIBUTED.md（一般來說都會有，而且必看！）

Review

• 專案維護者通常會指定人選來進行 Review
• Review 也算是貢獻的一環，會在你的活動紀錄算上一筆
• 介面其實跟 issue 討論很像，不過可以針對你修改的程式碼提出引用，並且逐行審核，超棒的！

結語

這篇文章就是鐵人賽的最後一篇產出，明天的內容會寫些心得，並統整 30 天的文章，謝謝你的觀賞～